       ********    **************************************************
             *    *                                                  *
            *     *                 The independent guide to BITNET  *
           *      *                                                  *
          *       *                                     March, 1988  *
         *        *                                                  *
        *         *                              Volume 2, Number 9  *
       ********   *                                                  *
                  *                                                  *
        ***       *                                                  *
       * * *      *                                                  *
       * * *      *                                                  *
       * * *      *                                                  *
       * **       *                                                  *
                  *                                                  *
           *      *                                                  *
           *      *                                                  *
       ******     *                                                  *
           *      *                                                  *
           *      *                                                  *
                  *                                                  *
       ********   *                                                  *
             *    *                                                  *
            *     *                                                  *
           *      *                                                  *
            *     *                                                  *
             *    *                                                  *
       ********   *                                                  *
                  *                                                  *
        ***       *                                                  *
       *   *      *                                                  *
       *   *      *                                                  *
       *   *      *                                                  *
        ***       *                                                  *
                  *                                                  *
       ******     *                                                  *
           *      *                                                  *
           *      *                                                  *
           *      *                                                  *
       ****       *                                                  *
                  *                                                  *
           *      *                                                  *
           *      *                                                  *
       ******     *                                                  *
           *      *                                                  *
           *      *                                                  *
                  *                                                  *
       ********   *                                                  *
           *      *                                                  *
           *      *                                                  *
           *      *                                                  *
       ****        **************************************************
1


            *     *              *     *                   *
            **    *         *    **   **       *       *   *
            * *   *  ***  *****  * * * *  ***  ****  ***** ****
            *  *  * *   *   *    *  *  * *   * *   *   *   *   *
            *   * * *****   *    *     * *   * *   *   *   *   *
            *    ** *       *    *     * *   * *   *   *   *   *
            *     *  ****   *    *     *  ***  *   *   *   *   *
       *****                                                    ******


       Christopher Condon    Editor                  CONDON @ YALEVM
       Mike Patrick          Contributing Editor    PATRICK @ YALEVM
       Timothy Stephen       Contributing Editor    STEPHEN @ RPICICGE
       Craig White           Contributing Editor     CWHITE @ UA1VM
       Glen Overby           Technical Assistant   NU070156 @ NDSUVM1
       Gary Moss             Staff Supervisor          MOSS @ YALEVM


       ********************  Contents - Issue 19  ********************


       EDITORIAL PAGE_________________________________________________

       Bitnotes .................................................... 1
       The Human Factor ............................................ 3
       Forty-two ................................................... 8
       Comments of a So-so Happy Crossnet User ..................... 9
       Flames To: ................................................. 11

       FEATURES_______________________________________________________

       NetCon88 ................................................... 13
       foNETiks ................................................... 15
       The DECWRL Archive Server .................................. 16
       CDNet and EAN .............................................. 18

       DEPARTMENTS____________________________________________________

       Headlines .................................................. 20
       Helpdesk ................................................... 21
       Feedback ................................................... 22
       Policies ................................................... 23


       *  For information on  subscribing to  NetMonth,  submitting  *
       *  articles, sending  letters, and  printing this  file, see  *
       *  the "Policies" section on the last pages of this issue.    *


       -----------------------------------------

                A publication of the Bitnet Services Library
1

                                                                Page 1


        *********
       *         *  Bitnotes
       *         *
       *         *  by Christopher Condon
       *         *
       *         *  CONDON@YALEVM
        *********


                      "You can't get there from here."


       I have a  large,  yellow notebook in my  bookcase,  filled with
       notes and printouts from my first months in BITNET.   There are
       old node lists, documentation on long-forgotten servers,  early
       issues of FSFNET...  a treasure trove of network history.   You
       might say  that the notebook  is the  beginning of all  we have
       come up with in the past few years.  Everything from Bitlist to
       NetWeek has it's origins in those tattered pages.

       When looking through  those printouts,  I realize  how much the
       network has changed over the past few years.  Oh, it has grown,
       to be  sure,  but there are  other,  less obvious,   changes to
       consider.    The very  way in  which we  access information  in
       BITNET has  been altered...   dependant upon  the actions  of a
       relatively small number of individuals.

       For example, take LISTSERV (please).   In little over a year it
       has become  the dominant  type of  server in  BITNET,  changing
       drastically the way we communicate.   It has made mailing lists
       and forums  the norm  rather than  the exception.    Previously
       there were a  few well-informed people who  belonged to ARPANET
       mailing lists (SF-LOVERS and INFO-NETS  come to mind),  but the
       vast majority of people knew nothing of these.  The most common
       information  resources   were  file   servers  and   electronic
       magazines.

       Enter, stage left, LISTSERV.   The first BITNET list server was
       developed and installed by BITNIC.    It worked fairly well but
       did not receive much in the way of support or accolades.

       Enter, stage right,  Eric Thomas at FRECP11 and his improvement
       on the  concept of  the mailing  list server.    What he  added
       (among other  things)  was  the ability for  a mailing  list to
       exist at multiple servers by "peering" the lists.  People could
       subscribe to a list at a  LISTSERV close to their node,  rather
       than subscribe at a cental location.   This spread out the load
       which would be caused by a  mailing list,  rather than bog down
       the links around a central list server.
1

                                                                Page 2


       More importantly,   the spread  of these  servers made  mailing
       lists accessable to everybody.  You'd like to start a forum for
       people interested in pond scum?   Contact the coordinator for a
       a nearby LISTSERV and ask him about it.   You want to subscribe
       to an ARPANET mailing list?   There  is a LISTSERV nearby where
       you can  send your  request.   The growth  in mail  volume over
       BITNET has been tremendous.

       All  of this  might not  have  happened if  Eric Thomas  hadn't
       decided to improve upon the original LISTSERV concept.  PERHAPS
       someone else would have thought of it, and PERHAPS someone else
       would have taken the time to produce such a server, but I doubt
       it.

       A similar turn of events took place a few years earlier.  Henry
       Nussbacher  took  the time  to  point  out the  weaknesses  and
       problems with single-node conference machines.   Jeff Kell took
       it upon himself to address these  problems.   Today we have the
       Relay  Conference Machine  system,   allowing real-time  BITNET
       conversations among  groups of people  (as opposed to  only two
       people).

       These and other  contributions by a few  determined people have
       changed and improved  the way we access  information in BITNET.
       They have,  in fact,  become  prime selling points in promoting
       the use of  the network.   I am not suggesting  that these Eric
       Thomas and  Jeff Kell did this  on their own.   There  are many
       people  who have  worked very  hard  to build  and support  the
       Listserv and Relay systems we have today.  However, the initial
       effort, sacrifice, inspiration,  (whatever you want to call it)
       was theirs alone.

       This is keeping with the original spirit of BITNET:   A network
       where most  of the development and  support were provided  on a
       voluntary basis.  It is to the people who gave their time while
       the network was growing that we owe  round of thanks,  a pat on
       the back,  a pedestal on which  to stand,  praises sung it jazz
       harmony....

       Now that  I have  established the religion,   allow me  to play
       Devil's Advocate and trample on it.

       Where does this  voluntary effort lead us?    Some applications
       get extreme  attention (Listserv)  while development  on others
       doesn't get a  second thought?   Who decides  what services are
       important enough to work upon and  which ones are not?   Are we
       held by the whim of a Rexx  programmer somewhere who may or may
       not decide to develop the next major server?  If he/she doesn't
       do it, will someone else?
1

                                                                Page 3


       What  if someone  builds  an alternative  to  Listserv that  is
       better,  faster,  and more efficient?   Will a working Listserv
       network be  dismantled?   Who  would supervise  the transition?
       Would there be any, or would the idea die on the vine,  crushed
       by the popularity of the current system?

       To but it bluntly:

       Who will coordinate servers and services in BITNET?

       Who is planning the future of BITNET, if at all?

       Who is at the helm?


                         Virtually,

                              Chris Condon@YALEVM


        *********
       *         *  The Human Factor
       *         *
       *         *  by T. D. Stephen
       *         *
       *         *  STEPHEN@RPICICGE
        *********


       Last  month,  in  an  aside during  my  discussion of  BITNET's
       culture and its specialized language,   I challenged readers to
       find a common language equivalent  for that ghastly phrase,  so
       familiar to  many who use BITNET  on CMS systems,   "spool your
       virtual punch to rscs" (in fact, what one actually types is "sp
       pun to rscs  cl m").   I'm sorry to report  that that challenge
       has not been satisfactorily met.  The one attempted translation
       I  received  took half  a  screen  and  began with  "Send  your
       electrons...".    It was  an interesting  effort,  but  nothing
       beginning with  "Send your electrons..."  is quite what  we are
       after.

       "Spool", I understand, is actually an acronym for "Simultaneous
       Peripheral Operations On-Line"  and provides a good  example of
       how fantastically  obscure network  communication concepts  can
       be.   Not only is "simultaneous  peripheral operations on line"
       entirely  without meaning  for  anyone who  is  not a  computer
       specialist  (try  turning   conversation  toward  "simultaneous
       peripheral operations on-line"  the next time your  family gets
       together), but it's acronym, "spool",  actually misleads in its
       apparent association with the weaving trades.   "RSCS" ("Remote
       Spooling and Communications Subsystem"),   the other acronym in
1

                                                                Page 4


       that phrase and a gem in its own right,  at least doesn't steer
       you wrong in its associations.   Since it has no vowels, it can
       be readily filed as just another vague acronym.

       Requiring users to type "spool pun to rscs cl m" before sending
       mail over BITNET is linguistic tyranny, pure and simple.  It is
       a bit like the public schools  requiring children to recite the
       pledge of  allegiance.   In many  cases young children  may not
       understand the significance  of what they are  uttering and may
       not even get the words right.    But they do understand that it
       is  somehow   important  that  they   engage  in   the  ritual.
       Similarly,   anyone interested  enough in  BITNET  to make  the
       effort learns that,   whether "sp pun to rscs  cl m" ultimately
       means anything or not, it's the right thing to type.   From the
       user's point of view, being required to type "sp pun to rscs cl
       m"  is no  more sensible  than  being required  to chant  "nasa
       flapjack to naacp  form 1040a" before being allowed  to use the
       rest room.

       Primitive computer concepts like "sp pun  to rscs cl m" are not
       unique to IBM CMS computers.  Try a Unix system sometime if you
       want to experience  this phenomenon at its  hair-raising worst.
       There,  when you want to see a list of the names of all of your
       files, you type "ls";  when you want to see the names of all of
       the  files that  contain the  word "flapjack,"  you type  "grep
       flapjack." Even  more awe-inspiring in  its obscurity,   in its
       utter disregard for common sense, in its sheer nose-thumbing at
       the user's  frame of  reference --  to list  the contents  of a
       particular file on your screen,  you type "cat" followed by the
       name of  the file (the  new user  wonders if typing  "dog" will
       send the file to the printer).

       The newcomer to BITNET confronts a maze of obscure concepts,  a
       fog of "techno talk"  that we simply have to lift  if BITNET is
       to become a  useful tool.   You can argue,  if  you wish,  that
       every academic specialty requires newcomers to learn unfamiliar
       terms and  obscure ideas  and you would  be correct.    Even in
       human  communication   studies  newcomers   confront  "sememe",
       "kinemorph",  "pentad",  "talkover",  and  "double interact" to
       mention only a few.  But BITNET is meant to be a service, not a
       discipline of study.   And in order to be a useful service,  it
       needs  to communicate  with its  users  in a  manner that  they
       understand and find familiar.

       Not long  ago computer communication  systems were  used almost
       exclusively  by computer  scientists and  engineers  and it  is
       sensible that the language system they evolved to work with the
       technology  would  reflect  their own  habits  of  thought  and
       economies of expression.   In fact, the creation of the "spool"
1

                                                                Page 5


       process  marked  an  important technological  advance  and  its
       metaphoric reference  to winding threads  around a  cylinder is
       not  inappropriate given  what actually  occurs when  computers
       "spool" things  (thanks to John  Fisher,  RPICICGE,   and David
       Chess, IBM Yorktown, for this information).   However, now that
       the  technology  has  moved  from  the  specialized  domain  of
       computer  scientists  and  has  been placed  in  service  as  a
       communication medium  for as diverse  an audience as  exists in
       higher education,   there is a  profound need to  translate its
       operational concepts  to ones that  are appropriate  for people
       with little time and sometimes, I'm afraid,  little interest in
       computer science itself.

       To  accomplish  this,   many sites  have  obtained  or  created
       software that protects users from  having to confront primitive
       commands like "sp pun to rscs cl m".   Here at RPI's Center for
       Interactive  Computer  Graphics,   for example,   we  can  type
       "Bitnote"  and  a  much friendlier  program  comes  alive  that
       handles sending mail  over BITNET without the  user ever having
       to type or even think about "sp pun to rscs cl m".  The Bitnote
       program also  packages the mail  in a  way that saves  the user
       from having to learn about  RFC822,  the "standard" for network
       mail.   This  is a good thing  because reading about  RFC822 is
       enough  to drive  anyone from  BITNET for  life.   (The  RFC822
       document  is  available  from Nicserve@Bitnic  as  file  RFC822
       STANDARD,  but  take my  word for it,   you'd rather  read your
       income tax forms.)

       Though many  sites provide  Bitnote or  an equivalent  program,
       there are  others that do not  and in some cases,   though such
       programs are provided,   not enough has been done  to let users
       know that they exist.   The University of Connecticut maintains
       a program  named "Memo" that is  similar to Bitnote but  to use
       it, users have to create a "link"  to a detached "virtual mini-
       disk" and then "access" the disk.  Although a little program is
       provided to help users to do this, the extra step is apparently
       enough  to  keep  people  away.   Most  of  the  mail  that  my
       colleagues from  Uconnvm  send  continues  to  arrive  in  non-
       standard formats.   Comserve users from a number of other sites
       seem to be similarly disadvantaged.

       "Bitnote" is a particularly good  name for that program because
       its associations imply  its purpose -- Bitnote is  used to send
       "notes" over "BITNET".  Bitnote comes easily to both the tongue
       and  the fingers,   and  is not  built  upon  obscure words  or
       concepts  like the  Unix "cat"  command.   "Cat"  is,  in  some
       strange way,  short for "concatenate",  a word that should have
       been avoided since "join" or "combine"  could have done as well
       and  are far  more commonly  used  (of course,   the fact  that
1

                                                                Page 6


       listing a file on your terminal  screen has nothing whatever to
       do  with joining,   combining,   or  concatenating anything  is
       another problem).

       The  suffix  "serve",   derived  from  "file  server",   as  in
       "Netserv", "Nicserve", "Bitserve", "Comserve", etc.   is also a
       poor choice, although I think it is here to stay.  Serving is a
       weak metaphor  for what  these programs  actually do  and "file
       servers" are something that computer specialists relate to, not
       ordinary people,   not the  educational and  research community
       that BITNET ostensibly is in place  to serve.   "CSNews" was an
       excellent  choice  for  an  information  service  for  computer
       science  and  "Relay"  a  defensible choice  for  a  method  of
       relaying messages.   The choice of "Listserv",  however,  was a
       mistake for a service that is,  potentially,  the most valuable
       asset of BITNET.  People rarely aspire to belong to "lists" and
       if  the name  has  any metaphoric  value at  all,   at best  it
       suggests  that Listserv  is  where one  goes  to  get lists  of
       things, which, of course, it is not.   A similar system that is
       available to local users on RPI's  MTS system is called "Forum"
       -- a much better name.

       The  social  entities  that form  via  Listserv  are  sometimes
       referred to as "groups", sometimes "conferences", and sometimes
       just  "lists"  (as in  "I'm  a  member  of the  Mail-L  list").
       Obviously, people do not form into "lists",  but,  perhaps less
       obviously, what occurs via Listserv does not much resemble what
       happens in group or conference interaction either.  Our feeling
       at Comserve was  that what usually happens on  Listserv is more
       like what happens on hotlines than  anything else -- people use
       them to deliver news or write  asking for help;  others respond
       with  advice or  opinion.   Since  we switched  to calling  our
       "lists" "hotlines," we've found it easier to orient faculty and
       students to the service.

       I  think  it a  failure  of  foresight  that so  many  computer
       commands and programs have been inappropriately named.   Anyone
       who has brought a child into the  world -- or has been close to
       new parents  -- knows how much  care and thought goes  into the
       selection of a name.   We all recognize that the name we choose
       will influence  the way  that the  world relates  to the  child
       throughout  life.   Why  has this  simple truth  been so  often
       ignored in  the realm of  computers and technology?   Why,  for
       example,   was  a  sophisticated  file  transfer  and  terminal
       communications program,  "Kermit",  named  after a frog puppet?
       What did the authors of "Grand" hope to accomplish by naming it
       that?  What did the Unix community have in mind when they chose
       "finger" as the  name for a command that tells  you who another
       user is?   Did they  expect that  Unix would  be popular  among
       mobsters?
1

                                                                Page 7


       Even in the choice of the name "BITNET", it would seem that the
       desire to communicate our  technological orientation outweighed
       whatever advantage  might have been  gained by choosing  a name
       that  said  something  about  the  network's  purpose  or  user
       population (but perhaps this wasn't  clear during the network's
       beginnings).   Interestingly,  the Europeans chose differently:
       "EARN"  stands for  "European Academic  and Research  Network".
       "BITNET" is a jazzier acronym than "EARN".  But when you unpack
       it  ("Because  It's  Time  Network")  it  is  unclear  what  it
       communicates except,  God forbid,  that  we are the network for
       Ernest and Julio Gallo's production vineyards.

       BITNET's  limitations and  problems  are  often discussed  with
       reference  to its  technology.    Items  such as  queue  sizes,
       transmission speeds,  limitations in the RSCS network protocol,
       and  ambiguities   in  the   RFC822  standard   are  frequently
       identified as  key problems,   the solutions  of which  are not
       self-evident,  cheap,   or easily implemented.    However,  the
       quality  of  service  provided  by  BITNET  could  be  improved
       substantially,  quickly,  and  at little cost if  only we would
       give  more  consideration  to  the  frames  of  reference  that
       characterize  the population  that  BITNET serves.    Immediate
       gains could be  made if the names of the  commands and services
       that are related to using the network were brought in line with
       the language of every day life.

       Perhaps  Shakespeare did  us a  disservice when  he had  Juliet
       question whether  Romeo Montague would  be any different  if he
       had been named something else ("What's in a name? That which we
       call  a  rose  by  any other  name  would  smell  as  sweet.").
       Frankly,  if he had been named "Sp-pun-to-rscs-cl-m Montague" I
       doubt if their romance would have ever gotten off the ground.


        *************************************************************
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
        *************************************************************
1

                                                                Page 8


        *********
       *         *  Forty-two
       *         *
       *         *  by Mike Patrick
       *         *
       *         *  PATRICK@YALEVM
        *********


                     "I'm goin' down, down, down, down."

                                           - Bruce Springsteen

       Hello boys and girls.   Welcome  to my neighborhood.   Today we
       are going to learn all about "links".  Can you say "links"?   I
       knew you could!

       A link, as defined by the dictionary, is "anything connecting a
       single part of  a series or chain".    Therefore,  those meaty,
       cylindrical  wads  of  pig  flesh you  eat  for  breakfast  are
       "sausage links".    Those cloudy  pictures of  Bigfoot and  the
       abominable snowmen for which Leonard  Nimoy is always searching
       are called  "missing links".   The  things that  connect Relays
       from all over  the world are called "Relay  links".   These are
       the focus of our lesson today.

       To illustrate the  operation of BITNET "links",   let's talk to
       our friend Mr.  Mudface.  You remember Mr.  Mudface, don't you,
       boys and girls?

       TELL RELAY Hello Mr. Mudface!  How are you today?
       FROM YALEVM(RELAY):  Hi, Mike.  What do you want?
       TELL RELAY Well, I thought you might talk to us about "links"
       FROM YALEVM(RELAY): ]signoff] User MUDFACE @ MUD (Mr_Mudface)
       TELL RELAY Mr. Mudface? Hello? Mr. Mudface?

       Well,  boys and girls,  it looks  as though the links went down
       again.   We'll have to talk to Mr.  Mudface about links another
       time.

       FROM YALEVM(RELAY): ]signon] MUDFACE @ MUD (Mr_Mudface)

       Oh! He's back!  Now we'll find out about "links"!

       TELL RELAY Hi! How about telling us all about "links" now?
       FROM YALEVM(RELAY):  Sure, Mike.  I'll tell you
       FROM YALEVM(RELAY): everything you need to know about them.
       TELL RELAY How come they keep going down, Mr. Mudface?
       FROM YALEVM(RELAY): ]signoff] User MUDFACE @ MUD (Mr_Mudface)
1

                                                                Page 9


       They're down again.   Oh well,  boys and girls.   I think we've
       covered enough ground on the subject of "links" for today.  Can
       you  say,   "AAAAAAARRRRGGGGGGHHHHH!    The   links  went  down
       again!!!!" ?  I knew you could!

       Next time,  I'll teach you how to sell Cheerios to your friends
       by telling them they're doughnut seeds.   Until then,  bye boys
       and girls!


        *********
       *         *  Comments of a So-so Happy Crossnet User
       *         *
       *         *  by Eric Keller
       *         *
       *         *  R34334@UQAM
        *********


       I've  used  BITNET  for  about  a year  now  and  I'd  rate  my
       satisfaction  with BITNET  fairly high.   But sending  messages
       across the network boundaries is still downright hazardous. I'd
       like to suggest a number of ways  to improve a service which is
       bound to become increasingly important as time goes on.

       First some background:  I teach at a large, urban university in
       Canada and run a research lab  on speech processing.  I use the
       nets between  four and  six times a  week to  exchange messages
       with colleagues in Canada,  the US and Europe.  I receive three
       network bulletins, including NetMonth. I regularly (attempt to)
       send  messages to  other networks,   particularly EDU,   Janet,
       Internet  and  NetNorth.  Recently, I have set up a SIG for the
       phonetic   sciences   and   my   e-mail   volume  has  gone  up
       considerably.  I  have   15  years'  computer  user  experience
       on  a variety of large,  medium and small machines  and have as
       many  years' experience as a  programmer with languages ranging
       from Z80 assembler to C and LISP.

       All that to say  that I'm quite used to  dealing with computer-
       related problems.  I never give up  on the first try and always
       try  again.  Still  I have  found  networking,  and  especially
       contacting  people on  other networks,   to  be a  particularly
       resistant problem. I'll give a few examples.

       1. Mail to an EDU address was returned with "addressee unknown"
       (or words to that effect)   because the SENDGATE EXEC converted
       lower case  into upper case  and the destination  node required
       lower case.   Fortunately, the CROSSNET EXEC preserves case and
       was able to do the job instead.
1

                                                               Page 10


       2. Colleagues from the FR network in France can get mail to me,
       but I haven't found a way of getting mail back to them. No luck
       trying  to use  the return  address  marked on  the message  by
       BITNET.

       3. I have a  colleague on NETNORTH, a Canadian academic network
       who sent me  a reference last Monday  evening and it got  to me
       Wednesday noon.   The irony is  that his  lab is only  about 10
       miles away from mine.

       4. As of late January, the version of CROSSNET on our mainframe
       was still trying to channel mail to EDU via WISCUM.  So I tried
       to  see  if  I  could  get a  newer  version  from  the  Guelph
       University LISTSERV  (CANADA01).  I got  as far as  the NETSERV
       REFCARD. When I requested GET NETSERV FILELIST, or GET PROGRAMS
       FILELIST (as instructed by the REFCARD),  or GET CROSSNET EXEC,
       or  GET SENDGATE  EXEC,  I  got the  message "no  such file  on
       LISTSERV" (or similar). Foiled again.

       As  it  turned  out,  the  newest version  of CROSSNET EXEC was
       added to the LISTSERV about two weeks later  and it now handles
       EDU and JANET okay.  But the point is  that for a while,  there
       was a very frustrated network user out there. Someone less used
       to trying and trying again might well have given up a long time
       ago.

       5. And finally a site-internal problem. We have a mail facility
       on our Amdahl mainframe that cuts  off the last letter of long,
       but legal BITNET names. As a result, letters to perfectly well-
       specified addresses are returned as "addressee unknown".  I now
       use SENDFILE  to send  out texts  that are  either uploaded  or
       created with XEDIT to get around that problem.

       And so it goes.  Once you know how to navigate around the major
       obstacles,  mail within BITNET is reasonably fast and reliable.
       But crossing  the gulf  to the other  networks is  hazardous at
       best.   The promise  is  there,  but  the  delivery is,   well,
       mediocre. How can the service be improved?

       First of all, we need a reliable,  more complete and up-to-date
       mail exec.   From the  user's point  of view,   that's priority
       number one.  We don't like delays,   but we can live with them.
       Undeliverable mail,   on the  other hand,   is wasted  time and
       energy.   From what  I can  figure out,   neither SENDGATE  nor
       CROSSNET  can presently  handle  access  to ALL  networks  that
       BITNET/EARN is connected to.  So some  work needs to be done to
       update one or the  other or both of these execs.   And let's be
       clear: don't expect users to have to specify anything more than
       userid,  node  and network.  That's it.   No backwards-forwards
1

                                                               Page 11


       ordering of pathnames, for instance.  Simply, an exec that does
       ALL  the  work for us,  and  that prompts  us for the necessary
       information if it has to.

       Second,  all BITNET users should have  easy access to an up-to-
       date version of such an exec. The best way to do this--and I am
       quite unequivocal about this--is to  make them available on the
       nearest  LISTSERV.    On-site  servicing  is  spotty   in  many
       institutions,  and the  LISTSERVs are the natural  places where
       interested users should be able to obtain their execs.

       Third,  attack the  strange  phenomenon  of one-way  crossings.
       There are few  frustrations greater than being  able to listen,
       but not being able to speak.   Being able to receive mail,  but
       not being able to send it is a close second.

       Concretely,  that means:  pay someone for  a summer to build or
       adapt an easily maintainable exec that handles all the networks
       and  that provides all the necessary prompts,  and make sure it
       gets posted to all LISTSERVS.  Then tell  us all about it,  and
       maintain the exec religiously. I wonder if that couldn't be put
       somewhere very high on the BITNET development priority list.


        *********
       *         *  Flames To:
       *         *
       *         *  by Craig White
       *         *
       *         *  CWHITE@UA1VM
        *********


       Hello again,

       How many folks were able to find a copy of Toward an Ethics and
       Etiquette for Electronic Mail this past month?   If you did,  I
       hope you'll  return it to the  library promptly so  that others
       may enjoy the thoughts that it provokes.   This month has flown
       by for me and quite frankly,   I've had trouble keeping up with
       my incoming mail.   A couple of  times this month I've ended up
       with over 200  unread files in my incoming box.    I noticed in
       the mail  that I  was able to  read that a  lot of  people have
       begun to include a disclaimer  in their mail-list transactions.
       I hope more people will adopt the practice.

       I sometimes  have paranoid thoughts  about things and  a recent
       one surrounds mail-lists.    It goes like this:   When you send
       something out  for public  distribution,  you  are volunteering
1

                                                               Page 12


       information about yourself to the world at large.  Imagine your
       chagrin when a prospective employer at an interview pulls out a
       folder with laser printed copies of several of your more choice
       submissions to ETHICS-L  and asks is this really  how you think
       about thus  and so?   Or  worse yet what  if you don't  get the
       interview for the  same reason as above?   Oh well,   on to the
       good stuff.

       First order of business:   I notice that a lot of mail seems to
       be generated  with a  story line  like "brand  Y's computer  is
       better  than brand  Z's computer  (or  operating system)."   It
       seems to me that this kind  of message is totally uncalled for.
       At my  site for instance,  we  recently changed from  brand Y's
       computer to brand Z's computer.    There were the typical kinds
       of "wish we could just keep on using Y's" and the "this Z can't
       do this like Y's computer would".   Now that brand Y's computer
       is no longer available and hasn't been for sometime,  this kind
       of talk seems to have died down and more people are focusing on
       how to get the results that they want out of the Z computer.  I
       suppose what I'm trying to say  here is that instead of wasting
       your precious time and energy coming  up with that one argument
       that will convince all those brain-dead Z computer users to see
       the light and make the switch to Y,  you should try to get most
       out of your Y, and let the Z users do the same.  In addition to
       your brain bandwidth,   our net bandwidth can  probably use the
       break just as much as my bit-bucket key can.

       Spelling Checkers:   One of the things that surprises me is the
       number of  misspelled words that go  out on mail-lists.    I am
       willing to bet that over 97  percent of the computers on BITnet
       have a spelling checker.  The questions is why don't people use
       them?   If you haven't already noticed, I have this thing about
       the appearance that you project to people, and using a spelling
       checker is  one of the  ways that you  can make sure  that your
       appearance is  enhanced.   It seems  to me that  some questions
       posed to mail-lists  get more responses than  others.   I think
       that a carefully worded, correctly spelled query is more likely
       to get responses  than one that is poorly  constructed and full
       of misspelled words.  At times I'm really surprised at the mail
       on  the  lists  from  people  you  look  up  to,   like  system
       programmers, node administrators,  and bright programmers whose
       mail is full of misspelled words.  I think that that one simple
       maneuver  would  certainly  enhance the  effectiveness  of  the
       answers that you submit.

       Flames to  me:   Now that I  have ranted and raved  about spell
       checkers let me flame myself this month about a typo I sent out
       in last month's Flames To.  I noticed, too late of course, that
       I had typed an l for an I.   My spelling checker on this stupid
1

                                                               Page 13


       Z didn't catch it.   This month  I'm using a different spelling
       checker and it will catch that kind of thing, I hope.  Now will
       it also help out on verb tenses?   Well,  its spring break time
       here in Alabama and  I've about run out of fuel  for the flames
       this month.   I'll be here next month and as always if you have
       questions,  comments or  flames about this column  send them to
       CWHITE@UA1VM.


        *********
       *         *  NetCon88
       *         *
       *         *  by the NetCon Committee
       *         *
       *         *  NETCON-L@NCSUVM
        *********


       NetCon(tm)  is a "con" or a mini-convention that is planned and
       coordinated by computer users,  like yourself,  whose main link
       is the BITNET.   NetCon88 offers you a chance to meet the "face
       at the other end," meaning that you can finally meet the people
       to  whom  you have  spoken  on  Relay,  CSNEWS,   or  directly.
       NetCon88 allows you  to meet many  of these people  at the same
       time,  in the same location (convenient,  eh?).   You also have
       the opportunity  to visit a  new city  and take in  the sights.
       NetCon88 will also feature speakers whose topics range from the
       birth  of the  Relay to  the  future of  the networks  (BITNET,
       NetNorth, EARN,the InterNet, etc.).

       * Time  and Place:    NetCon88 will take  place May  27-30,  in
       Tempe, Arizona.

       * Travel Information:  Piedmont Airlines has been designated as
       the official carrier for the attendees of the NetCon,  May 27 -
       30,   1988,  in  Phoenix,  AZ.    Piedmont agrees  to offer  an
       exclusive, low fare for the attendees.   This special fare will
       offer a 5% savings off any published Piedmont promotional round
       trip  fare for  travel within  the  Continental United  States,
       providing all rules and restrictions are met.

       For attendees unable  to meet the restrictions  for promotional
       fares,  Piedmont  will offer  a 35%  discount off  the standard
       round trip  day coach  fare for  travel within  the Continental
       United States, and a 25% discount for travel from Canada.

       Additional restrictions  apply for  discounts on  international
       travel.
1

                                                               Page 14


       These convention discounts are valid between May 24 and June 2.
       To obtain this  convention discount,  you or  your travel agent
       must call Piedmont's Convention Sales office at 1-800-334-8644;
       from North Carolina and Canada, 1-800-251-5720, Ext. 2224; from
       Bahamas, 1-800-423-8814, Ext. 2224; Monday through Friday, 8:30
       AM - 6:00 PM, Eastern Time.

       If you prefer  to travel by train,  you should  phone Amtrak at
       1-(800)-USA-RAIL.   They should be able to help with scheduling
       and costs.

       Also if you are planning to drive  to NetCon please send a note
       to Reba Taylor (REBAT@VTVM1).  She is trying to help people get
       to NetCon with low travel expenses.   If you need a ride or can
       offer a ride  or be of help,  it would  be greatly appreciated.
       Please do  not wait too long,   or a good opportunity  might be
       missed.

       * Hotel Information:   All meetings and lodgings will be at the
       Sheraton Tempe Mission Palms Hotel.  This hotel is not far from
       the Phoenix airport,  and is only blocks from the Greyhound bus
       depot.   The hotel is near the downtown area of Tempe, so there
       are shops,  restaurants,   and nightclubs in the  area.   Rates
       vary, depending on the number of persons in the room:

             1-- $50 per night, totalling $150 + tax for the weekend.
             2-- $25 per night, per person, totalling $75 + tax.
             3-- $18.34 per night, per person, totalling $55.02 + tax.
             4-- $15 per night, per person, totalling $45 + tax.

       A deposit of  one night's lodging must  be sent to us  when you
       register  for  NetCon88,   so  that   we  can  make  your  room
       reservations for you.  (see below)

       * Registration Fees:    The following fees must  accompany your
       NetCon88 registration.

             $15  (or more) -- One night's lodging for room deposit.
             $15            -- NetCon88 registration fee.
             $ 5            -- Membership fee in NetCon(tm) Society.

       You should mail this to:

             Bill McBrayer
             518 W. Howe St.
             Tempe, Az 85281

       You should also send Bill a note at C9M5R@ASUACAD notifying him
       of your intentions to attend NetCon.
1

                                                               Page 15


        *********
       *         *  foNETiks
       *         *
       *         *  by Eric Keller
       *         *
       *         *  R34334@UQAM
        *********


       There was  much acclaim  when I  first proposed  the idea  of a
       network  newsbulletin   for  the  phonetic  sciences   to  some
       colleagues at  the November 1987 Western  Hemisphere Conference
       of IsPhS.  Seated around a big,  round table at the Villa Capri
       Restaurant in Miami  Beach were the unwitting  founding members
       of the  bulletin:  (in alphabetical  order)  George  D.  Allen,
       Claire Gelinas-Chebat,   Jim Flege,   Terence M.   Nearey,  Kim
       Silverman,   and myself.   We  quickly came  up  with the  name
       (foNETix -  which I  unilaterally chose  to adapt  to foNETiks,
       mostly in  deference to the IPA,   but also to  prevent abusive
       comparisons with  ASTERIX),  and  we took note  of some  of the
       items foNETiks should carry: current information about hardware
       and software available for phonetics,  current abstracts in the
       phonetic sciences,  perhaps current titles in phonetics-related
       journals,  info  on phonetics  meetings,  and  (gulp)  phonetic
       humor.

       Back  in  Montreal,  I  drew  up  a  short description  of  the
       Bulletin.  I envisaged two versions, a network version in ASCII
       characters  only,  and  a printed  version  of Macintosh  laser
       printing quality,   with the  possibility of  printing phonetic
       characters as  well as illustrations.   I sent  the description
       into the  four winds via  the electronic academic  networks and
       via snail mail.  For addresses, I used a mailing list we use at
       our research center,  plus the address  list I gathered at last
       year's Franco-British  phonetic sciences  meeting in  Brittany,
       France.  All told, I sent off well over 100 notices.  I figured
       that if the thing took off,  I would send further copies out to
       all members  of ISPhS  (the International  Society of  Phonetic
       Sciences)   and AAPS  (the  American  Association for  Phonetic
       Sciences). Then I sat back for a month.

       The responses trickled in. After a month, some 10 people wished
       to  have the  electronic  version of  the  bulletin.  None  had
       subscribed to the printed version.   There were some hints that
       there might be some contributions to come, but as of January 8,
       I had essentially no material to print. Clearly, the tremendous
       effort required to put out two versions of the bulletin was not
       in  keeping with  the response  shown  to the  pre-announcement
       materials.  So I drew up a "Sorry, foNETiks is dead" letter and
       sent it out to everyone who had contacted me.
1

                                                               Page 16


       The response  was interesting.  Several  people wrote  back and
       suggested that instead, we set up an informal mailbox bulletin.
       I would  simply act as a  distributing center and  everyone who
       wanted to could send me  contributions.  My only responsibility
       would be to  copy all the information into one  bulletin and to
       send it out.

       Okay, why not,  I thought.  At least till my next sabbatical in
       1991,  I can indeed collect the info  and push it out again via
       the academic networks  to all those who would like  to have it.
       In other words, I would be a moderator, and not an editor.  And
       in 1991, we can see what happens.

       To  subsscribe  to  foNETiks,    send  mail  R34334@UQAM.    To
       contribute to foNETiks, send your material to the same address.
       Optionally,  you may send your material  by regular mail to the
       address  given  in   the  title  bar.   Your   text  should  be
       unformatted,  i.e.,   contain no extra  spaces,  and  should be
       written  using the  ASCII  32-127 set  only.   This means,   no
       accented characters, underlines, etc.  You can expect your text
       to be included,   pretty much no questions asked,   in the next
       issue of "foNETiks".


        *********
       *         *  The DECWRL Archive Server
       *         *
       *         *  from the DECWRL documentation
       *         *
       *         *  ARCHIVE-SERVER@DECWRL.DEC.COM
        *********


       ARCHIVE-SERVER@DECWRL.DEC.COM is a mail-response server.   This
       means that  you must  send all  commands to  through electronic
       mail.

       Each command you send ARCHIVE-SERVER must  be the first word on
       a line.  The archive server reads your entire message before it
       does anything,  so you can have several different commands in a
       single message.  You can use any combination of upper and lower
       case letters in the commands.

       The archives  are organized  into a  series of  directories and
       subdirectories.    Each  directory  has  an  index,   and  each
       subdirectory has  an index.  The  top-level index gives  you an
       overview of what  is in the subdirectories,  and  the index for
       each subdirectory tells you what is in it.
1

                                                               Page 17


       COMMANDS:

       HELP:  The command HELP or SEND  HELP causes the server to send
       you a help  file.   No other commands are honored  in a message
       that asks for help (the server figures that you had better read
       the help message before you do anything else).

       INDEX:  If  your message  contains a line  whose first  word is
       INDEX, then the server will send you the top-level index of the
       contents of the archive.  If there are other words on that line
       that match  the name of  subdirectories,  then the  indexes for
       those subdirectories are  sent instead of the  top-level index.
       For example, you can say

           INDEX
         or
           INDEX PROGRAMS
         or
           INDEX RECIPES

       You can then  send back another message to  the archive server,
       using a  SEND command (see  below)  to ask  it to send  you the
       files whose name you learned from that list.

       SEND: If your message contains a line whose first word is SEND,
       then the archive server will send you the item(s)  named on the
       rest of the line.  To name an item,  you give its directory and
       its name. For example:

           SEND RECIPE AFRICAN-STEW
         or
           SEND PROGRAM RCKEEP

       Once you have named  a category,  you can put as  many names as
       you like on the rest of the  line;  they will all be taken from
       that category. For example:

           SEND RECIPE CHOC-SHIP-1 CHOC-CHIP-2 CHOC-CHIP-3

       NOTES:

       The archive server  acknowledges every request by  return mail.
       If you  don't get  a message back  in a day  or two  you should
       assume that something is going wrong.

       Don't send  mail with long  lines.  If you  want to ask  for 20
       recipes in one request, you don't need to put all 20 of them in
       one "send" command.  The archive server is quite able to handle
       long lines,   but before your mail  message is received  by the
1

                                                               Page 18


       archive server it might pass  through relay computers that will
       choke on long lines.

       FAIRNESS:

       The archive server  contains many safeguards to  ensure that it
       is not monopolized by people asking  for large amounts of data.
       The mailer is set up so that it  will send no more than a fixed
       amount  of data  each day.   If  the work  queue contains  more
       requests than the day's quota,  then  the unsent files will not
       be processed until the next day.  Whenever the mailer is run to
       send its day's quota, it sends the requests out shortest-first.

       If you have a request waiting in the work queue and you send in
       another  request,  the  new request  is  added to  the old  one
       (thereby increasing  its size)  rather  than being  filed anew.
       This prevents you from being able to  send in a large number of
       small requests as a way of beating the system.   If you request
       10  recipes  together,    you  will  get  substantially  higher
       priority than if you make 10 requests for 1 recipe each.

       The reason for all of these  quotas and limitations is that the
       delivery  resources are  finite,  and  there are  many tens  of
       thousands of people who would like to make use of the archive.


        *********
       *         *  CDNnet and EAN
       *         *
       *         *  from the NETSERV documentation
       *         *
       *         *  NETWORKS FILELIST
        *********


       This is third in a series of articles about other networks.

       CDNnet is  a Canadian academic network  based on the  ISO model
       for Open  Systems Interconnection and  in particular  the CCITT
       X.400 Recommendations on Message Handling Systems (MHS). CDNnet
       presently has approximately 50 sites  at 20 institutions across
       Canada. The MHS software is a distributed message system called
       EAN.   EAN has  been  under development  at  the University  of
       British  Columbia since  late  1981.   A prototype  system  was
       operational immediately  after the Draft  X.400 Recommendations
       became available  in December 1983,  and  Version 1 of  EAN has
       been available since early in 1985.    The project is funded by
       the Natural Sciences and Engineering Research Council of Canada
       (NSERC).
1

                                                               Page 19


       EAN comprises a User Service, a Message Transfer Service, and a
       Directory  Service.   The  User Service  is  implemented  as  a
       collection of User Agents (UAs).   The User Service through its
       UAs assists in the preparation, posting, reception, and storage
       of  messages.   A  number  of types  of  UAs  are  implemented,
       including a mail program,  a  distribution list program,  and a
       "remote pipe" service.  Database and file transfer services are
       under development.  The Message Transfer Service is composed of
       a  collection  of  Message   Transfer  Agents  (MTAs)   located
       throughout the  network,  with each  MTA being  responsible for
       receiving messages from and delivering  messages to a number of
       UAs. MTAs also perform routing, transfer messages reliably, and
       provide interim storage as required. The Directory Service maps
       names to addresses.  It also optionally maintains a profile for
       each registered  name including  such information  as home  and
       office   addresses,   telephone   numbers,    and  a   personal
       description.

       As well  as being used in  CDNnet,  the EAN software  forms the
       basis  for   academic  networks  in  several   other  countries
       including  Norway  (UNINETT),    Sweden  (SUNET),   Switzerland
       (CHUNET),  and West Germany (DFN).   The software is also being
       used in CERN, Italy, Great Britain, Netherlands,  Spain,  South
       Korea,    and  Australia.    The   per-CPU   licence  fee   for
       educational/research use of  EAN is $500 Canadian  for Canadian
       sites and $1500 for others.  EAN is commercially available from
       Sydney Development Corporation in Vancouver, British Columbia.

       CDNnet addresses are of the form:

               user@subdomain.cdn

       For example:

               FRED@EAN.UBC.CDN

       Information about  EAN  and  CDNnet  is  available  from  <EAN-
       HELP@EAN.UBC.CDN>.


        *************************************************************
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
       *                                                             *
        *************************************************************
1

                                                               Page 20


        *********
       *         *  Headlines
       *         *
       *         *  Smaller chunks of news, but not unimportant...
       *         *
       *         *  BITLIB@YALEVM
        *********


       * Relay news:  Users of CSRLY@VTVM2, please be advised that the
       server has been renamed to the network-standard RELAY@VTVM2.

       * SERVER@TAMCBA is no more:  A message from Rick Troth: "SERVER
       at TAMCBA  received almost  nil usage for  a number  of months.
       That,  coupled  with a shortage of  disk space,  (what  else is
       new?)  prompted  us to  take it  down."  Archives  for PSYCHNET
       magazine  which  were  stored  on SERVER  are  also  stored  on
       LISTSERV@TCSVM.

       * A NETMONTH Filelist:   Marc Shannon  has set up a FILELIST on
       LISTSERV@CMUCCVMA for NetMonth and NetWeek archives. For a list
       of files,  send the following  command to the CMUCCVMA LISTSERV
       via mail or message:

             INDEX NETMONTH

       * Please  note:   Remember  that  all  servers  do  not  accept
       commands by mail.  Some, such as NYSHARE@WEIZMANN,  only accept
       interactive messages.  Changes are being made to BITNET SERVERS
       in order to provide this information.

       * The  OS9 Filelist:    In addition  to the  COCO (Tandy  Color
       Computer)  FILELIST,  LISTSERV@PUCC now offers an OS9 FILELIST.
       The files  there are  usable under  the OS-9  operating system.
       More information is  available by requesting the  files CURRENT
       INFO and COCO MEMO from LISTSERV@PUCC.  To get a list of files,
       send  the server  the command  INDEX  OS9.  Thanks  to Eric  W.
       Tilenius for this information.

       * Another MACSERVE:  As of 20th February MACSERVE@IRLEARN began
       providing services  identical to MACSERVE@PUCC.  The  server at
       Princeton will  no longer serve sites  on the European  side of
       the Atlantic.   This should help  in reducing unecessary trans-
       atlantic traffic.

       * Whois:   The /WHOIS name modification  has been added  to two
       more list  servers:   LISTSERV@CMUCCVMA,   and LISTSERV@UCF1VM.
       This LISTSERV also running the /WHOIS name server feature.
1

                                                               Page 21


        *********
       *         *  Helpdesk
       *         *
       *         *  a Question and Answer column
       *         *
       *         *  Send your questions to BITLIB@YALEVM
        *********


       *Q*  Who should  be informed  when chain  letters are  received
       through BITNET?

       *A* Most chain letters come from  people who simply do not know
       any better.  When I recieve a chain letter I chastize...  er...
       explain to the  sender why this is NOT an  intelligent thing to
       do  (generally  citing  network load).    Since  sending  chain
       letters does not break any specific  BITNET rules (it is merely
       stupid and annoying) I wouldn't make a big deal out of it (that
       just generates more mail!).


       *Q* I just entered TELL LISTSERV AT CMUCCVMA INDEX NETMONTH and
       got back:

        FROM OHSTMPA: REJECTED BY TASK VMA -- PREVIOUS COMMAND ACTIVE

       What "previous command" (I haven't sent  an cmd message in that
       direction for  DAYS)?   Why is Ohio  State sticking its  oar in
       anyway,  the "command"  isn't for it (have we got  some sort of
       RSCS conflict message here)?   If this is some sort of bug, who
       do I gripe to about it?

       *A* from Marc Shannon:  It's not your fault.  The error message
       you got is a common one on  busy links.   What it means is that
       the internal  RSCS queue of messages  is full and  cannot store
       your new message  until there is room.    The "Previous command
       active" is  not necessarily  yours.   The only  thing to  do is
       either  wait about  10-15 minutes  and  try again  or send  the
       request via mail.


       *Q/A* Here is an update on sending binary files by Karl Noell:

       Besides UU-coding there is  still another methode:   BOO-coding
       mainly used  to distribute  Kermit bin-files.    These encoding
       schemes  converts  every  three  consecutive  bytes  into  four
       printable characters,  blowing  up the filesize by  at least 33
       percent.   If you  intend to ship any binary  stuff between two
       IBM Hosts,   it's best,   to transfer  those files  "as is"  by
       SENDFILE  in   NETDATA  format,    which  ensures   a  reliable
       transparent transmission.
1

                                                               Page 22


        *********
       *         *  Feedback
       *         *
       *         *  I love fan mail...
       *         *
       *         *  Send your letters to BITLIB@YALEVM
        *********


       From:     Richard Lee Holbert
       Subject:  NetWeek, NetMonth

       Just wanted to repeat my thoughts  that you and your co-workers
       are doing a great job. The NetWeek mail has really been helpful
       and interesting and fits right into the NetMonth with such ease
       that it is not noticeable. Keep up the fantastic work!!!


       From:     Juan M. Courcoul
       Subject:  The January and February NetMonth


       Several quick notes for Netmonth,  done in a hurry cause I have
       class real soon and I didn't want to miss the deadline !

       First,  I wanted to congratulate  you for NetMonth's new format
       and regular features. They're great !!

       The  editorial and  the section  "The Human  Factor" were  very
       good, in the January issue.  I hope we can see more articles on
       that  vein,  because  it's  very true  that  BITNET is  grossly
       underutilized by the  undergraduates,  who could get  much more
       from it.    I've also tried to  circulate the issue as  much as
       possible here  at my campus,  as  well as the Mexico  State and
       Queretaro campus of  our system,  in an attempt  to promote the
       net's use.

       Last of all, congrats.  for the NetWeek idea !  Neat,  also.  I
       guess it's a lot  of work,  but I'm sure all  your avid readers
       (like myself)  really appreciate the  effort.   Thanks for your
       time and dedication.


       From:     Rita Saltz
       Subject:  Whew!

       Pretty fancy issue there!   Tim Stephen turned out to be a good
       idea, huh?  Really replete and most of it Other People's Prose,
       and new stuff at that.  Nice job.
1

                                                               Page 23


        *********
       *         *  NetMonth Polices
       *         *
       *         *  Everything you ever wanted to know...
       *         *
       *         *  BITLIB@YALEVM
        *********


       NetMonth is a  network service publication distributed free  of
       charge to  students  and  professionals  in  BITNET  and  other
       networks. This magazine and its companion file, BITNET SERVERS,
       are the  work  of the  BITNET Services Library (BSL) staff  and
       contributors from around the network.

       BITNET SERVERS is BITNETs list of servers and services.  If you
       know of servers not listed in BITNET SERVERS, or if some listed
       are no longer available, please contact the NetMonth Editor.

       * Subscribing to NetMonth and BITNET SERVERS:

       Send  the  following  command  to  LISTSERV@MARIST  by  mail or
       messgage:

            SUBSCRIBE NETMONTH Your_full_name

       Internet users may use this method, but must  address  the mail
       to LISTSERV%MARIST.BITNET

       * Back issues:

       BITNET users  may get NetMonth back issues from the list server
       LISTSERV@CMUCCVMA.  For a list of issues,  send  the  following
       command to the server via mail or message:

            INDEX NETMONTH

       A subscriber  can delete  him/herself from  the mailing list by
       sending LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command.

       * Letters to the Editor:  If  you  have  questions  or comments
       about BITNET or  NetMonth that you would like  to  see  printed
       here, mail  your letter  to BITLIB@YALEVM.  Make  sure that you
       specify in the "Subject:"  header or  somewhere  in  the letter
       that it is for the NetMonth letters column.

       * Article Submissions:  The  only  requirements  for   NetMonth
       articles and columns are that they be informative, interesting,
       and concern some BITNET-related topic.  Send your articles  and
       to BITLIB@YALEVM.
1

                                                               Page 24


       * Printing this file:  VM  users can print  this file  by first
       copying it to NETMONTH LISTING and then printing  the new file.
       This will allow page-breaks and other formatting to be accepted
       by your printer.


            _
           __-
          __---    The
         __-----   Bitnet
        __-------  Services
       ___________ Library                       "Because We're Here."

       ***************************************************************